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BACKGROUND OF THE INVENTION 



10 are developed and their designs upgraded and/or enhanced, so to are the assennbly 
language instruction-set architectures (ISAs) used for the processors. Instructions 
may be added to the ISA of the processor to take advantage of previously unseen 
features, or to add performance features to the processor. 



ry 15 the machine-readable object code that can by executed by a processor 12, or run on 
7" an instruction-set simulator (ISS) 14. As Fig. 1 shows, a source code file (File.asm) 
^ 20 containing source code assembly language instructions is applied to an 
ry assembler (asm) 22, running on a computing unit (not shown). The assembler 22 

operates to convert each of the assembly language instructions contained in 
O20 File.asm to machine language translations (object code) that are written to an object 
file (Fiie.obj) 24. The object file is then applied to a linker (Ink) 28 to merge object 
code modules, resolve references, etc. as is conventional, to produce a unitary 
program executable by the processor 12 or the ISS 14. The linked result is written 
by the linker 28 to an executable file (File .exe) 30. 
25 However, the design of ISAs, or their corresponding processors, are 

not frozen in stone. As is often the practice, a next-generation processor is designed 
with features of its predecessor. This, in turn, is accompanied by a redesign of the 
ISA to include additional assembly language instructions that will take advantage of 
those features added to the next-generation processor, but keeping many if not all of 
30 the assembly language instructions of the prior ISA. In some cases instructions may 
be added to an ISA without a concomitant change of the processor to take 
advantage of features not fully appreciated before. 



Fig. 1 diagrammatically illustrates assembly of source code to produce 



Of course, these developmental changes in the processor 12 of Fig. 1 , 
or in the current ISA, or both, will result in a new or extended ISA. While the current 
assennbler remains available to assemble the old instructions included in the new 
ISA, it will be incapable of handling the new. added instructions. Thus, a new 
5 assembler is required to interpret and convert (to object code) the added instructions 
as well as the older instructions. Now, as Fig. 2 illustrates, a source code file 20', 
containing both old assembly language instructions 20a and new instructions 20b, 
requires a newly-developed assembler 22' to produce machine language object code 
for both the new and old instructions 20a, 20b. As before, the object code produced 

10 by the new assembler is written to file 28 to produce, when linked by linker 28, 
executable code executable by the new processor 12' and/or the new ISS 14\ 

'^'^^^ Unfortunately, this development effort usually has different groups of 
designers workrng on different aspects of the design. That is, development of the 
new simulator to&l (ISS 14') for the new ISA is often the responsibility of the team 

15 that is also responsible for developing the new ISA. But. development of the new 
assembler may be Responsibility of a different team - often in a different geographic 
location, or worse. aVjifferent (third party) organization. This means that testing and 
debugging of the newMSA, or even the new ISS, must await completion of the new 
assembler. This makes it difficult for the assembler program to change quickly, 

20 much less allow it to change over a period of time as the extended ISA evolves. The 
developers of the extended ISA and new ISS must wait until the design and 
development of the new assembler is finished before using it to debug the extended 
ISA by compiling test programs, which may, in turn, necessitate changes in the 
assembler, and so on. This\is a reiterative procedure that makes the overall task of 

25 changing processor/ISA desigris a lengthy process. The current or old assembler is 
of no use in this development effort because it is incapable of properly interpreting 
and converting the new instructions. 

Existing methods attempt to accelerate the development of the new 
assembler to support the new instructions, but this does not do away with the 

30 reiterative process described above. 

Thus, it can be seen that there is a need for a technique to be able to 
assemble code for a new ISA containing new instructions so that the development of 
an extended ISA can continue concomitant with the development of the new 
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assembler and software assets upgraded to the new ISA before the product 
assembler is developed. 

SUMMARY OF THE INVENTION 
5 The present invention provides a simple and effective method of 

assembling instructions of a new assembly language instruction set architecture 
using the old assembler to produce a machine language program executable by the 
new instruction-set simulator, or a new processor, if available. 

Broadly, the invention is a method of using the old assembler to 

10 assemble source code containing both old and new assembly instructions of a new 
ISA to produce corresponding object code. According to an embodiment of the 
invention, the source code is first examined by a preprocessor that writes each old 
instruction to a temporary file unchanged. When a new instruction is encountered in 
the source code, it is written to the temporary source file as inserted data 

15 representing the object code equivalent of the new instruction. The temporary 

source file is then applied to the old assembler, which converts the old instructions to 
their corresponding object code, but passes over the inserted data, leaving the 
inserted data representing object code for the new instructions. The result is then 
linked using the existing (old) linker, producing a machine language program that 

20 can be executed by the new ISS or the new processor. 

It will be apparent to those skilled in this art that the method of the 
present invention provides a number of advantages. First is that the design team in 
charge of the development of the new ISA need not wait until the new assembler is 
provided to test the new instructions of the new ISA. When the new assembler is 

25 finally available, the new ISA can be ready as a solid benchmark tool for the new 
assembler. 

These and other advantages and aspects of the invention disclosed 
herein will become apparent to those in this art upon a reading of the following 
description of the specific embodiments of the invention, which should be taken in 
30 conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a diagrammatic illustration of the prior art process used to 
convert an assembly language listing to an executable machine language program; 
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Fig. 2 is a diagrammatic illustration of the prior art process used to 
convert an assembly language containing both old and new assembly language 
instructions of a new ISA to an executable machine language program; 

Fig. 3 is a diagrammatic illustration of the present invention to convert 
5 an assembly language containing both old and new assembly language instructions 
of a new ISA to an executable machine language program using the current (old) 
assembler; 

Figs. 4A and 4B are flow diagrams that illustrate the steps taken 
according to the present invention to convert an assembly language program, 
10 containing both old and new assembly language instructions of a new ISA to object 
code using the old assembler. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
ie present invention, as noted above, is a technique for employing an 
oid^r assembler tQ produce executable object code from a source code containing 
tl5 old assembly language instructions, compatible with the older assembler, and 
I added, new assembly latMuage instructions not capable of being interpreted by the 

older assembler. The inverHjpn uses the data directive feature usually found 
] presently available in assemble applications. Such data directive features are 
J capable of taking an argument, usually in hexadecimal format, and inserting that 
]20 argument in the object code unchangi 

^ Turning now to the figures,^d for the moment Fig. 3, there is 

illustrated a diagrammatic representation of the method of the present invention as 
implemented on a processing system (not shown). As Fig. 3 shows, an original 
source file (File.asm) 40 contains old assembly instmctions 40a (OldJnst_1 and 

25 Old Jnstr__2) and new assembly instructions 40b (mov>^l @r1 +r8, y1 ) that form a part 
of a new ISA. The original source file 40 is applied to a pi;eprocessor (pp) software 
application 42. The preprocessor 42 operates to scan the sburce file 40, create a 
temporary source file 46, and write to the temporary source filers, unchanged, the 
old assembly instructions 40a. 40b. 

30 Each new instruction 40b encountered by the preproce^pr 42 is 

checked for validity and, if found to be a valid instruction, converted to its^bject code 
equivalent. That object code equivalent is then also written to the temporary^urce 
code file 46 as the argument of a data directive 41 , which usually takes the form 
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J A [data]". Thus, as Fig. 3 illustrates, the new instruction 40b, "movx.l @r1+r8. 
y1", is coi1vet4ed4Qjtsobject code equivalent, "12AB" (Hex), and inserted in the 
temporary source code file4§'^S-the.4rgunrient of the data directive statement 41 . 
Each data directive statement 41 will be place3Trh4beinstruction sequence of the 
temporary source code file 46 at the same location (relativeTolhe-othai^j^^ 
40) corresponding new instruction 40b appeared in the original source code file^d.. 

The temporary source code file 46. containing now the old assembly 
language instructions 40a (unchanged) and, for each new assembly language 
instruction 40b, a corresponding data directive 41, is then assembled in conventional 
fashion, using the old assembler application program 48, and written to an object file 
(Fil^bj) 50. 

^^^^^ Although the old assembler is capable of converting the old instructions 
4Qa<ftfectly to iheir object code equivalents, it would have been incapable of 
handling the ne|w instructions 40b. However, when the old assembler 48 encounters 



jl5 a data directive 



argument of the data directive, as indicated, the object code equivalent of the new 



instruction 40b, 
appears now in 
of both the old 



in the source file, such as the data directive 41 . it will use the 



and insert that object code equivalent in the object file 50. What 
the object file 50 are the machine readable object code equivalents 
instructions 40a of the original source code 40 and, added as data by 
the data directives they were converted to. the object code equivalents of the new 
instructions 40f . 

The object file 50 may then be linked, using the old linker 52, to create 
an executable file (File, exe) 54 that may be run on a newly-developed instruction- 
set sirnulator 56 or. if available, the new processor 58 developed for the new ISA. 

urning now to Figs. 4A and 4B, the steps taken to assemble an 
aj&^mbly langujage program containing new and old instructions according to the 
invention is illustrated. Fig. 4A broadly shows the steps taken by the control script 
44, while Fig. 4B shows the principal steps taken by the preprocessor 42. 

Turnina first to Fig. 4A, when the control script 44 is invoked, it will first 
call the preprocessorY2 in step 70, passing to it two arguments: the identification of 
the source code file 4(Aand the name of the temporary output file (File.tmp) to be 
created. Control is then\passed to the preprocessor 42, the main operative steps of 
which are outlined in Fig. 
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Turning then to Fig. 4B. it will be seen that the preprocessor 42 will 
first, in step 80, create the temporary file 46, giving it the temporary filename 
File.tmp. Next, in step 82, the preprocess 42 will scan the original source code file 
40, instruction by instruction. For each instruction, in step 84, the preprocessor 42 
5 will determine if the instruction is an old instruction 40a or a new instruction 40b. If it 
is an old instruction 40a, step 84 will be left in favor of step 86, where the instruction 
is written to File.asm (temporary) 46. Step 88 checks to see if all instructions have 
been processed. If not, the preprocessor procedure will return to step 82 to scan the 
next instruction in the File.asm 40. If not, step 90 returns to the control script 44 at 
10 A. 

If, in step 84, it is determined that the instruction is a new instruction, 
step 84 is left in favor of step 92, where the instruction is checked to ensure it is a 
^ valid "new" instruction. If the validity check fails, an error is generated, and the 

preprocessing stops. Assuming the instruction is found valid, the preprocessor 42 
^il5 will proceed to step 94, where the instruction is converted to its operation code (op 
^ code) equivalent. In essence, step 94 involves parsing the instruction to build the 

i y 

=p new operation code from symbolic constant definitions of operation code fragments 
and register encodings to form the binary equivalent of the instruction. That binary 
ry equivalent, once constructed, is then converted to an ASCII hexadecimal value and, 
nj20 that, in step 96, written to the temporary source code file 46 as data, using a data 
S insertion directive (e.g., ".DATA"). Step 96 is followed by step 88 to determine if 
there are still instructions in the original source code file 40 that have not been 
written, either directly or as inserted data, to the temporary source code file 46. If so, 
steps 84, 86. 88, 92, 94, and 96 are continued. 
25 Once all instructions of the original source code file have been 

processed, the preprocessor will exit at A (step 90). returning to the control script 44 
at step 72 where the two source files 40 and 46 are renamed. The original source 
file (File.asm) is saved by renaming it as File.sav, for example. (Alternately, it could 
be saved to a new directory, or renamed and saved to a new directory.) The 
30 temporary source file 46 (File.tmp) is given the name initially used for the original 
source code file 40: File.asm. Then, the control script 44 will move to step 73 to call 
the (old) assembler 48, recording with it the name of (temporary) File.asm 46. The 
assembler 48 will then process the temporary source code file 46, converting each of 
the old instructions 40a into their op code equivalents. When a data directive is 
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encountered, the data, which is the op code equivalent of a new instruction 40b. is 
inserted in the object code file 50 as part of the instruction stream. 

When the assembler has finished, the control script 44 will restore the 
original source code file in step 74. deleting the temporary file, and terminate with 
5 step 76. As is conventional, the file name of the source code file (now bearing its 
original name: File.asm) has been recorded in the object code, allowing the new ISS 
56 user to view and debug new instructions in their human readable (mnemonic) 
form rather than as ".DATA" directives. 
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